- Grab the UT432 public headers
- Download modernized surreal version of the headers here: https://github.com/stephank/surreal
- Remove all the packages from the public headers
- Add just Core and Engine from surreal
- Check Anthrax headers as well, and check for the differences in UnFile.h
- Open project in VS2010, let it convert
- Save it in the new format
- Remove old VS6 files
- Open VS2010 again
- Other stuff (FAQ):
	Q: Do the official public headers (v432) work with Visual Studio?
	A: Yes they do but there are a few things to keep in mind:
	Epic originally used Visual Studio 4.0 to work on UEngine. The most recent version of Visual Studio that works perfectly with the official headers is 6.0. You CAN (and probably should) use more recent versions of Visual Studio but then you need some slight modifications to the official headers. You can grab my modified headers here: http://utgl.unrealadmin.org/UTHeaders.rar. These headers also contain a sample project file for Visual Studio 6.0. You might also notice that I've made lots of annotations in the headers. These annotations are irrelevant for 99.9% of the people so feel free to ignore them.
	UEngine 1 has its own implementations of the C++ memory allocation operators (new, delete) in UnFile.h. If you include Core.h (which in turn includes UnFile.h), all of your memory allocation operations will be handled by UEngine's memory allocator. Sadly, this memory allocator has some serious limitations. The most severe limitation is thread-safety. It is NOT safe to use new, new[] or delete in a multi-threaded UT mod _unless_ you strip out the overridden operations in UnFile.h. Long story short: if you want to build a multi-threaded mod, you should define UTGLR_NO_APP_MALLOC in your preprocessor definitions. This will automagically comment out UEngine's overridden memory allocation operators.
	If you want to use a more recent VS version than 6.0, then stay away from TArray<BYTE>. The compiler will completely flip out if you attempt to use BYTE arrays. I never really bothered to figure out why.

	Q: Are there any project settings I need to change to build a mod with Visual Studio?
	A: Yes, depending on your version of VS, there might be quite a few of them. Here's a list:
	In the General section, you should specify Unicode as the default character set.
	In the Linker->Input section, you have to add Core.lib and Engine.lib as additional dependencies.
	If you're using an old version of VS then you have to enable Incremental Linking manually in the Linker->General section.
	In the C/C++->General section, you'll have to add Core\Inc, Engine\Inc and any folder that contains headers for your project as additional include directories.
	In the C/C++->Preprocessor section you should have the following preprocessor definitions: UTGLR_NO_APP_MALLOC (if your mod is multithreaded), _CRT_SECURE_NO_WARNINGS (if you're using VS.net 2003 or later), DEBUG and _REALLY_WANT_DEBUG (if you're building a debug version of your mod).
	In the C/C++->Language section you should disable "Thread wchar_t as built-in type" and you should enable "disable construction displacement" (only for older VS versions)
	In the C/C++->Core generation section you should set the struct member alignment to 4 bytes. In this same section, you should use either "Multi-Threaded Debug" as the runtime library (if you're building a debug version) or "Multi-Threaded" (if you're building a release build). If you're not using either of these options then VS will dynamically link your mod with the VC++ Runtime Library that came with the compiler. For VS 6.0 this is not a problem, since the game shipped with the VS 6.0 runtime library. If you're using a more recent version then the players might have to manually install the appropriate runtime library. This is especially problematic if you're using VS.net 2003 since that runtime library only came with .NET framework 1.1, which is now deprecated. If you're using VS 2005 or 2008, it is relatively safe to dynamically link with the runtime library (most people will have that installed by default). If you're using VS 2010 or 2011, static linking is recommended.

	Q: Is it possible to build native mods for Linux?
	A: Yes, it is in fact possible but I strongly discourage you to do so unless you really know what you're doing. If you ABSOLUTELY need a native mod for Linux then here's what you need to keep in mind:
	UT's native Linux client was compiled using the the ancient GCC 2.95.x compiler. Code generated by this compiler is binary incompatible with code that was generated by GCC 3.x or later. This is mainly due to a change in the C++ name mangling conventions. I do believe that there were some changes in the exception frame format and in the calling conventions as well but I never really checked this. In short, just install GCC 2.95.4...
	UT's original v436 Linux client does not export the __Context::Env symbol in Core.so. A quick peek at UnFile.h will show you that this has some serious implications. If you want a native mod to work with v436, you should NOT use the guard/unguard/unguardf macros (they all rely on that __Context::Env symbol). If you don't necessarily want compatibility with this version then guard/unguard/unguardf is allowed...
	Unlike the windows version, the linux version will not automagically cast FStrings to TCHAR* pointers. As such, this will work in Windows but not in Linux:
	FString Test(TEXT("123"));
	GLog->Logf(TEXT("Test = %s"), Test);

	This however works fine for both platforms:
	FString Test(TEXT("123"));
	GLog->Logf(TEXT("Test = %s"), *Test);
	For reasons I won't post in public, please don't ask me for help if you're having problems with your Linux mods.

	Q: Which compiler flags do I need for GCC?
	A: Here's a list:
	Mandatory compiler flags: -D__USE_GNU -D_GNU_SOURCE -D_REENTRANT -D__LINUX_X86__ -fno-for-scope -fexceptions
	Optional compiler flags: -O2 -fomit-frame-pointer
	Mandatory linker flags: -Wl,--traditional-format -Wl,--eh-frame-hdr -shared -lm -ldl -lpthread

	Q: Is it possible to build native mods for MacOS?
	A: Only in theory. It would take a ludicrous amount of time to actually pull it off. It would probably have worked with the v468 client but that was never released in public.


- After this there the entire project should compile properly
- Change the "TEXT(" macro to "UTEXT(" [since TEXT conflicts with windows.h if this header gets used, which is very very likely in case external libraries are intended to be used as well)
- Make sure that the engine headers are included last (after windows.h and other library links, remember that the engine ones are still outdated)
- Disable incremental linking (Project properties > Linker > General > Enable Incremental Linking > NO)

- To link and compile:
	* remove .u file
	* ucc make -ini=<path to make.ini of uscript side>
